Preliminary Evaluation of a Formal Approach to User Interface Specification

In this paper we report on a research project in which the user interface for a research nuclear reactor was specified using a combination of formal notations. The goal of the project was to evaluate the use of a combination of techniques and to assess their utility in specifying a user interface for a non-trivial safety-critical application. We conclude that the techniques worked well and scale up easily to the size of the application studied. restart if any process aborted (it does not), and that a watchdog timer would protect the system (it does not). In general, the development of user interfaces is a difficult and important problem. Because many errors in computer systems can be traced to defects in their specifications, a critical aspect of user-interface development is the specification of exactly what the user interface is to do. As safety-critical applications rely more heavily on increasingly complex user interfaces, the need to specify the user interface precisely and correctly in such systems becomes essential. Despite the importance of specification, in practice user interfaces are rarely specified with any degree of care. Most user interfaces evolve from an initial prototype implementation derived from an informal and incomplete description provided by application experts to a final implementation for which there is no specification. This evolution takes place as a series of iterations in which the implementation is demonstrated, evaluated by the application experts, and then enhanced. This is not an ideal situation and we hypothesize two reasons why it has arisen. The first reason is that the formal specification of a user interface requires a massive amount of detail if it is to be done properly. For example, to specify precisely the details of a pull-down menu on a computer screen requires detail such as colors, shape and appearance, and location as well as all the semantics associated with selecting a menu item. The second reason that we hypothesize to explain why user interfaces are rarely specified carefully is the variety of material that has to be specified. No single formal specification language has the facilities to describe all that is needed, and very few have any kind of animation mechanism that would permit application engineers to check that what is described is what they require. In two previous papers [3, 7] we have described an early version of an approach to formal specification of user interfaces that we have developed. In this paper, we present a preliminary evaluation of the approach based on the development of formal specifications for the user interfaces of two safety-critical systems: a medical robot and a nuclear reactor [6]. This latter system is the subject of a case study in which we are developing a prototype experimental (non-operational) control system for the research nuclear reactor at the University of Virginia. Examples from this project are used for illustration in this paper. The reactor specification was developed informally because its creation drove the refinement of the techniques described here. The requirements for the user interface were determined by examination of existing documentation, observation of the current system in operation, and extensive discussion with reactor operators and staff. Several reviews of different aspects of the specification have been held, and the user interface has been connected to a high-fidelity reactor simulator for user evaluation. All of these activities were informal and in no way validate the specification. Evaluation is ongoing. The specification approach that we are using employs three existing formal notations in an integrated framework—no new notations are involved. Our goals with the project that we describe are twofold. The first is to determine the capabilities that can be achieved and determine the difficulties raised by integrating more than one formal notations. The second goal is to evaluate the utility of the notations themselves in specifying the user interface for a non-trivial safety-critical application. In other words, how well do these techniques scale-up? We begin with an overview of the reactor application, and we follow this with a summary of the current version of the approach to specification that we have used. We then present examples of the specification taken from the reactor case study. These examples are followed by details of our evaluation criteria and our current evaluation results. Finally, we present our conclusions. 2 University Of Virginia Reactor The case study application providing most of the information for the evaluation of the specification technique is the University of Virginia Reactor (UVAR). This is a research reactor that is used for the training of nuclear engineering students, service work in the areas of neutron activation analysis and radioisotope generation, neutron radiography, radiation damage studies, and other research [23]. As part of a research program in software engineering, a digital control system is being developed for the UVAR and is currently in the specification stage.1 The UVAR is a “swimming pool” reactor, i.e., the reactor core is submerged in a very large tank of water. The water is used for cooling, shielding, and neutron moderation. The core uses Low Enriched Uranium (LEU) fuel elements and is located under approximately 22 feet of water on an 8x8 grid-plate that is suspended from the top of the reactor pool. The reactor core is made up of a variable number of fuel elements and in-core experiments, and always includes four control rod elements. Three of these control rods provide gross control and safety. They are coupled magnetically to their drive mechanisms, and they drop into the core by gravity if power fails or a safety shutdown signal (known as a “scram”) is generated either by the operator or the reactor protection system. The fourth rod is a regulating rod that is fixed to a drive mechanism and is therefore non-scramable. The regulating rod is moved automatically by the drive mechanism to maintain fine control of the power level to compensate for small changes in reactivity associated with normal operations [23]. The heat capacity of the pool is sufficient for steady-state operation at 200 kW with natural convection cooling. When the reactor is operated above 200 kW, the water in the pool is drawn down through the core by a pump via a header located beneath the grid-plate to a heat exchanger that transfers the heat generated in the water to a secondary system. A cooling tower located on the roof of the facility exhausts the heat and the cooled primary water is returned to the pool. The overall organization of the system is shown in Fig. 1. The existing reactor control system, shown in Fig. 2, is comprised primarily of analog instrumentation that is used by the reactor operators to monitor and regulate operating parameters over all ranges of operation, from start-up to full power. A firstgeneration of the digital control system will replicate the functionality of the existing control console. The majority of that functionality is the display of process variables 1. At present there is no intention of putting the digital control system into operation. including gross output, neutron flux and period, temperature difference between water entering the core and water leaving the core, control and regulating rod positions, primary system flow, and pool water level. The control console also provides facilities for operator input to the reactor system, including control of the regulating and control rods, a means to test instrumentation, and responses to unsafe conditions. 3 Specification Approach A user interface is a complex entity; specifying such an entity is correspondingly complex. The interface is far more than the graphics, the operator commands, or even these two combined. Informally, the items that have to be defined if a specification is to be in any sense complete include everything that is presented to the operator, everything that the operator can do to the interface, everything that it would be erroneous for the operator to do together with the actions that are required in each case, and the exact meaning of each input that the operator can enter. In a comprehensive approach to userinterface specification, all of the these aspects need to be addressed, and the specification technique(s) used must deal with each aspect completely and consistently. Formal specification of user interfaces is not new. Various texts [5, 10] and surveys [2] have been prepared, and many research contributions published. Some of the Fig. 1. The University of Virginia reactor system. Control Console Cooling Tower